1. Field of the Invention
This invention relates to the field of computer virtualization, that is, to systems and methods for implementing computers as software running on an underlying host hardware platform.
2. Description of the Related Art
Virtualization has brought many advantages to the world of computers. As is well known in the art, a virtual machine (VM) is a software abstraction—a “virtualization”—of a physical computer system that runs as a “guest” on an underlying “host” hardware platform. As long as a suitable interface is provided between the VM and the host platform, one advantage is that the operating system (OS) in the guest need not be the same as the OS at the system level in the host. For example, applications that presuppose a Microsoft Windows OS can be run in the VM even though the OS used to handle actual I/O, memory management, etc., on the host might be Linux.
It usually requires less than 10% of the processing capacity of a CPU to run a typical application, although usage may peak briefly for certain operations. Virtualization can more efficiently use processing capacity by allowing more than one VM to run on a single host, effectively multiplying the number of “computers” per “box.” Depending on the implementation, the reduction in performance is negligible, or at least not enough to justify separate, dedicated hardware “boxes” for each user.
Still another advantage is that different VMs can be isolated from and completely transparent to one another. Indeed, the user of a single VM will normally be unaware that he is not using a “real” computer, that is, a system with hardware dedicated exclusively to his use. The existence of the underlying host will also be transparent to the VM software itself. The products of VMware, Inc., of Palo Alto, Calif. provide all of these advantages in that they allow multiple, isolated VMs, which may (but need not) have OSs different from each other's, to run on a common hardware platform.
Example of a Virtualized System
FIG. 1 illustrates the main components of a system 10 that supports a virtual machine as implemented in the Workstation product of VMware, Inc. As in conventional computer systems, both system hardware 100 and system software 200 are included. The system hardware 100 includes CPU(s) 102, which may be a single processor, or two or more cooperating processors in a known multiprocessor arrangement. The system hardware also includes system memory 104, one or more disks 106, and some form of memory management unit MMU 112. As is well understood in the field of computer engineering, the system hardware also includes, or is connected to, conventional registers, interrupt-handling circuitry, a clock, etc., which, for the sake of simplicity, are not shown in the figure.
The system software 200 either is or at least includes an operating system (OS) 220, which has drivers 240 as needed for controlling and communicating with various devices 110, and usually with the disk 106 as well. Conventional applications 260, if included, may be installed to run on the hardware 100 via the system software 200 and any drivers needed to enable communication with devices.
As mentioned above, the virtual machine (VM) 300—also known as a “virtual computer”—is a software implementation of a complete computer system. In the VM, the physical system components of a “real” computer are emulated in software, that is, they are virtualized. Thus, the VM 300 will typically include virtualized (“guest”) system hardware 301, which in turn includes one or more virtual CPUs 302 (VCPU), virtual system memory 304 (VMEM), one or more virtual disks 306 (VDISK), and one or more virtual devices 310 (VDEVICE), all of which are implemented in software to emulate the corresponding components of an actual computer.
The VM's system software 320 includes a guest operating system 330, which may, but need not, simply be a copy of a conventional, commodity OS, as well as drivers 340 (DRVS) as needed, for example, to control the virtual device(s) 310. Of course, most computers are intended to run various applications, and a VM is usually no exception. Consequently, by way of example, FIG. 1 illustrates one or more applications 360 installed to run on the guest OS 330; any number of applications, including none at all, may be loaded for running on the guest OS, limited only by the requirements of the VM.
Note that although the hardware “layer” 301 will be a software abstraction of physical components, the VM's system software 320 may be the same as would be loaded into a hardware computer. The modifier “guest” is used here to indicate that the VM, although it acts as a “real” computer from the perspective of a user, is actually just computer code that is executed on the underlying “host” hardware and software platform 100, 200. Thus, for example, I/O to the virtual device 310 will actually be carried out by I/O to the hardware device 110, but in a manner transparent to the VM.
If the VM is properly designed, then the applications (or the user of the applications) will not “know” that they are not running directly on “real” hardware. Of course, all of the applications and the components of the VM are instructions and data stored in memory, just as any other software. The concept, design and operation of virtual machines are well known in the field of computer science. FIG. 1 illustrates a single VM 300 merely for the sake of simplicity, to illustrate the structure and operation of that single VM; in many installations, there will be more than one VM installed to run on the common hardware platform; all will have essentially the same general structure, although the individual components need not be identical. In fact, installations involving multiple VMs are of particular relevance to this invention.
Some interface is usually required between the VM 300 and the underlying “host” hardware 100, which is responsible for actually executing VM-related instructions and transferring data to and from the actual, physical memory 104. One advantageous interface between the VM and the underlying host system is often referred to as a virtual machine monitor (VMM), also known as a virtual machine “manager.” Virtual machine monitors have a long history, dating back to mainframe computer systems in the 1960s. See, for example, Robert P. Goldberg, “Survey of Virtual Machine Research,” IEEE Computer, June 1974, p. 54-45.
A VMM is usually a relatively thin layer of software that runs directly on top of a host, such as the system software 200, or directly on the hardware, and virtualizes the resources of the (or some) hardware platform. The VMM will typically include at least one device emulator 410, which may also form the implementation of the virtual device 310. The interface exported to the respective VM is usually such that the guest OS 330 cannot determine the presence of the VMM. The VMM also usually tracks and either forwards (to the host OS 220) or itself schedules and handles all requests by its VM for machine resources, as well as various faults and interrupts. FIG. 1 therefore illustrates an interrupt (including fault) handler 450 within the VMM. The general features of VMMs are well known and are therefore not discussed in further detail here.
In FIG. 1, a single VMM 400 is shown acting as the interface for the single VM 300. It would also be possible to include the VMM as part of its respective VM, that is, in each virtual system. Although the VMM is usually completely transparent to the VM, the VM and VMM may be viewed as a single module that virtualizes a computer system. The VM and VMM are shown as separate software entities in the figures for the sake of clarity. Moreover, it would also be possible to use a single VMM to act as the interface for more than one VM, although it will in many cases be more difficult to switch between the different contexts of the various VMs (for example, if different VMs use different guest operating systems) than it is simply to include a separate VMM for each VM. This invention works with all such VMNMM configurations.
In some configurations, the VMM 400 runs as a software layer between the host system software 200 and the VM 300. In other configurations, such as the one illustrated in FIG. 1, the VMM runs directly on the hardware platform 100 at the same system level as the host OS. In such case, the VMM may use the host OS to perform certain functions, including I/O, by calling (usually through a host API—application program interface) the host drivers 240. In this situation, it is still possible to view the VMM as an additional software layer inserted between the hardware 100 and the guest OS 330. Furthermore, it may in some cases be beneficial to deploy VMMs on top of a thin software layer, a “kernel,” constructed specifically for this purpose.
FIG. 2 illustrates yet another implementation, in which a kernel 650 takes the place of and performs the conventional functions of the host OS. Compared with a system in which VMMs run directly on the hardware platform, use of a kernel offers greater modularity and facilitates provision of services that extend across multiple virtual machines (for example, resource management). Compared with the hosted deployment, a kernel may offer greater performance because it can be co-developed with the VMM and be optimized for the characteristics of a workload consisting of VMMs.
As used herein, the “host” OS therefore means either the native OS 220 of the underlying physical computer, or whatever system-level software handles actual I/O operations, takes faults and interrupts, etc. for the VM. The invention may be used in all the different configurations described above.
Memory Mapping and Address Terminology
In most modern computers, memory is addressed as units known as “pages,” each of which is identified by a corresponding page number. The most straightforward way for all components in a computer to uniquely identify a memory page would be for them all simply to use a common set of page numbers. This is almost never done, however, for many well-known reasons. Instead, user-level software normally refers to memory pages using one set of identifiers, which is then ultimately mapped to the set actually used by the underlying hardware memory.
When a subsystem requests access to the hardware memory 104, for example, the request is usually issued with a “virtual address,” since the memory space that the subsystem addresses is a construct adopted to allow for much greater generality and flexibility. The request must, however, ultimately be mapped to an address that is issued to the actual hardware memory. This mapping, or translation, is typically specified by the operating system (OS), which includes some form of memory management module 245 included for this purpose. The OS thus converts the “virtual” address (VA), in particular, the virtual page number (VPN) of the request, into a “physical” address (PA), in particular, a physical page number (PPN), that can be applied directly to the hardware. (The VA and PA have a common offset from a base address, so that only the VPN needs to be converted into a corresponding PPN.)
When writing a given word to a virtual address in memory, the processor breaks the virtual address into a virtual page number (higher-order address bits) plus an offset into that page (lower-order address bits). The virtual page number (VPN) is then translated using mappings established by the OS into a physical page number (PPN) based on a page table entry (PTE) for that VPN in the page table associated with the currently active address space. The page table will therefore generally include an entry for every VPN. The actual translation may be accomplished simply by replacing the VPN (the higher order bits of the virtual address) with its PPN mapping, leaving the lower order offset bits the same.
To speed up virtual-to-physical address translation, a hardware structure known as a translation look-aside buffer (TLB) is normally included, for example, as part of a hardware memory management unit (MMU) 112. The TLB contains, among other information, VPN-to-PPN mapping entries at least for VPNs that have been addressed recently or frequently. Rather than searching the entire page table, the TLB is searched first instead. If the current VPN is not found in the TLB, then a “TLB miss” occurs, and the page tables in memory are consulted to find the proper translation, and the TLB is updated to include this translation. After the TLB miss fault is handled, the same memory access is attempted again, and this time, the required VPN-to-PPN mapping is found in the TLB. The OS thus specifies the mapping, but the hardware MMU 112 usually actually performs the conversion of one type of page number to the other. Below, for the sake of simplicity, when it is stated that a software module “maps” page numbers, the existence and operation of a hardware device such as the MMU 112 may be assumed.
The concepts of VPNs and PPNs, as well as the way in which the different page numbering schemes are implemented and used, are described in many standard texts, such as “Computer Organization and Design: The Hardware/Software Interface,” by David A. Patterson and John L. Hennessy, Morgan Kaufmann Publishers, Inc., San Francisco, Calif., 1994, pp. 579-603 (chapter 7.4 “Virtual Memory”). Patterson and Hennessy analogize address translation to finding a book in a library. The VPN is the “title” of the book and the full card catalog is the page table. A catalog card is included for every book in the library and tells the searcher where the book can be found. The TLB is then the “scratch” paper on which the searcher writes down the locations of the specific books he has previously looked up.
An extra level of addressing indirection is typically implemented in virtualized systems in that a VPN issued by an application 360 in the VM 300 is remapped twice in order to determine which page of the hardware memory is intended. A mapping module 345 within the guest OS 330 translates the guest VPN (GVPN) into a corresponding guest PPN (GPPN) in the conventional manner. The guest OS therefore “believes” that it is directly addressing the actual hardware memory, but in fact it is not. Of course, a valid address to the actual hardware memory address must, however, ultimately be used.
An address mapping module 445 in the VMM 400 therefore takes the GPPN issued by the guest OS 330 and maps it to a hardware page number PPN that can be used to address the hardware memory. From the perspective of the guest OS, the GVPN and GPPN are virtual and physical page numbers just as they would be if the guest OS were the only OS in the system. From the perspective of the actual host OS, however, the GPPN is a page number in the virtual address space, that is, a VPN, which is then mapped into the physical memory space of the hardware memory as a PPN. Note that in some literature involving virtualized systems, GVPNs, GPPNs, VPNs and PPNs are sometimes referred to as “VPNs,” “PPNs,” “VPNs” and “MPNs,” respectively, where “MPN” means “machine page number,” that is, the page number used to address the hardware memory. The problem is, though, that “VPN” is then used to mean the virtual page number in both the guest and host contexts, and one must always be aware of the current context to avoid confusion. Regardless of notation, however, the intermediate GPPN→PPN mapping performed by the VMM is transparent to the guest system.
Speed is a critical issue in virtualization—a VM that perfectly emulates the functions of a given computer but that is too slow to perform needed tasks is obviously of little good to a user. Ideally, a VM should operate at the native speed of the underlying host system. In practice, even where only a single VM is installed on the host, it is impossible to run a VM at native speed, if for no other reason than that the instructions that define the VMM must also be executed. Near native speed, is possible, however, in many common applications.
The highest speed for a VM is found in the special case where every VM instruction executes directly on the hardware processor. This would in general not be a good idea, however, because the VM should not be allowed to operate at the greatest privilege level; otherwise, it might alter the instructions or data of the host OS or the VMM itself and cause unpredictable behavior. Moreover, in cross-architectural systems, one or more instructions issued by the VM may not be included in the instruction set of the host processor. Instructions that cannot (or must not) execute directly on the host are typically converted into an instruction stream that can. This conversion process is commonly known as “binary translation.”
U.S. Pat. No. 6,397,242 (Devine, et al., “Virtualization system including a virtual machine monitor for a computer with a segmented architecture”), which is incorporated herein by reference, describes a system in which the VMM includes a mechanism that allows VM instructions to execute directly on the hardware platform whenever possible, but that switches to binary translation when necessary. FIG. 1 shows a direct execution engine 460 and a binary translation engine 462, for performing these respective functions. Combining these techniques allows for the speed of direct execution combined with the security of binary translation.
A virtualization system of course involves more than executing VM instructions—the VMM itself is also a software mechanism defined by instructions and data of its own. For example, the VMM might be a program written in C, compiled to execute on the system hardware platform. At the same time, an application 360 written in a language such as Visual Basic might be running in the VM, whose guest OS may be compiled from a different language.
There must also be some way for the VM to access hardware devices, albeit in a manner transparent to the VM itself. One solution would of course be to include in the VMM all the required drivers and functionality normally found in the host OS 220 to accomplish I/O tasks. Two disadvantages of this solution are increased VMM complexity and duplicated effort—if a new device is added, then its driver would need to be loaded into both the host OS and the VMM. In systems that include a host OS (as opposed to a dedicated kernel such as shown in FIG. 2), a much more efficient method has been implemented by VMware, Inc., in its Workstation product. This method is also illustrated in FIG. 1.
In the system illustrated in FIG. 1, both the host OS and the VMM are installed at system level, meaning that they both run at the greatest privilege level and can therefore independently modify the state of the hardware processor(s). For I/O to at least some devices, however, the VMM may issue requests via the host OS 220. To make this possible, a special driver VMdrv 242 is installed as any other driver within the host OS 220 and exposes a standard API to a user-level application VMapp 500. When the system is in the VMM context, meaning that the VMM is taking exceptions, handling interrupts, etc., but the VMM wishes to use the existing I/O facilities of the host OS, the VMM calls the driver VMdrv 242, which then issues calls to the application VMapp 500, which then carries out the I/O request by calling the appropriate routine in the host OS.
In FIG. 1, the vertical line 600 symbolizes the boundary between the virtualized (VMNMM) and non-virtualized (host software) “worlds” or “contexts.” The driver VMdrv 242 and application VMapp 500 thus enable communication between the worlds even though the virtualized world is essentially transparent to the host system software 200.
As described above, a primary advantage of virtual computer systems is the ability to run multiple VMs on a single host computer. Also as mentioned above, each VM may be a software implementation of a complete computer system. At the same time, the host world, comprising the host system software 200 and the applications 260, also constitutes a complete computer system. Thus, in effect, multiple complete virtual computer systems and one complete “real” computer system may run on a single physical computer system at the same time. All of these computer systems must share the same system hardware 100, however.
Various techniques have been used to allow system hardware to be shared between multiple virtual computer systems. For example, the VMM 400 may include a resource manager that switches the CPU(s) 102 between executing the multiple VMs and the host world so that each software entity is given time to execute on the CPU(s) 102. Other hardware resources must also be shared between the multiple VMs and the host world. For example, the system memory 104 and the disk 106 must also be allocated between the VMs and the host system.
Another hardware resource that must generally be shared between the host world and the multiple VMs is an interface to a computer network. Most computers these days have some sort of interface to a computer network, such as to a local area network (LAN) and/or to the global Internet. Many computers have a single network interface card (NIC), such as a standard Ethernet controller or a wireless NIC, for connecting to a computer network. FIG. 1, for example, shows a wireless NIC 108 within the system hardware 100. The wireless NIC 108 may implement a standard wireless networking interface, such as the 802.11a, 802.11b or 802.11g standards from the Institute of Electrical and Electronics Engineers, Inc. (IEEE), for example. Thus, the wireless NIC 108 may be a WUSB11 Wireless USB (Universal Serial Bus) Adapter, for example, from Linksys, a division of Cisco Systems, Inc. Alternatively, the system hardware 100 could have a conventional wired Ethernet controller, such as an Intel PRO/100 Ethernet NIC from Intel Corporation, for example.
Existing virtual machine products of VMware, Inc., the assignee of this application, enable a host world and a plurality of VMs to share a wired NIC to connect to an Ethernet network. For example, the Workstation virtualization software from VMware may be loaded onto a conventional Intel IA-32 computer system with a conventional NIC. The computer system may run a conventional OS, such as a distribution of Linux or a Windows OS from Microsoft Corp., along with a NIC driver that is appropriate for the OS and the NIC. The Workstation software may then be loaded onto the system, and configured to create one or more VMs and to enable the VMs to use the physical NIC to access a network. The Workstation product has three options for connecting a VM to a network: bridged networking, network address translation (NAT), and host-only networking. The bridged networking option is most relevant to this invention. Once the VMs are created, guest system software 320 and applications 360 may be loaded onto the VMs in a substantially conventional manner.
The system architecture of the Workstation product, such as Workstation 4, is substantially similar to the system illustrated in FIG. 1. The Workstation product has a separate instance of the VMM 400 for each VM 300 in the system. Each VMM 400 contains several device emulators 410, one of which is a NIC emulator 411. Each NIC emulator 411 may emulate one or more virtual NICs 308 for its respective VM, as illustrated in FIG. 1. More specifically, in the Workstation product, the NIC emulator 411 emulates an Am79C970A PCnet-PCI II Ethernet controller from Advanced Micro Devices, Inc. A PCnet Lance driver for this NIC is built into all common OSs. FIG. 1 illustrates a NIC driver 348 within the VM 300. The PCnet Lance driver is a specific implementation of the NIC driver 348. Thus, the NIC driver within each of the VMs can be used to access the respective virtual NIC.
Once a VM 300 is created and initialized, and a guest OS 330 is loaded into the VM, the VM can be configured to access a computer network to which the computer system 10 is connected. OSs generally come with a full stack of network software that is sufficient to enable applications to access a network. For example, modern Windows OSs include NIC drivers for common NICs, a Network Driver Interface Specification (NDIS) to support one or more higher level network protocol stacks, and at least one network protocol stack, such as an IP (Internet Protocol) stack. Other NIC drivers, network protocol stacks and other networking software, including possibly one or more intermediate drivers, may also be loaded into the OS to provide additional network capabilities.
In FIG. 1, the guest OS 330 is shown to contain a guest network software package 338, which may generally comprise any software that provides a networking interface between applications and a NIC driver. Hence, in a modern Windows OS, the network software package 338 may comprise the NDIS software and one or more network protocol stacks. The guest network software 338 may be configured in a conventional manner to interface with the NIC driver 348 in a conventional manner to use the virtual NIC 308 to access the computer network. From the perspective of the NIC driver 348, the guest network software 338, the guest OS 330 and the applications 360, the virtual NIC 308 is preferably indistinguishable from a corresponding physical NIC. So, these software entities within the VM 300 may be configured in a conventional manner and they may operate in a convention manner to access the network using the virtual NIC 308.
The NIC emulator 411 provides the functionality of the virtual NIC 308 to the VM 300. As is common practice in virtualization technology, a device emulator can provide an interface between a driver for the emulated device and a corresponding physical device. Here, the NIC emulator 411, possibly along with other software units within the virtual computer system 10, provides an interface between the NIC driver 348 and the physical NIC. The NIC emulator 411 provides the interface to the NIC driver 348 that the NIC driver is expecting from the virtual NIC 308, and the NIC emulator 411 initiates the transfer of network data between the NIC driver 348 and the physical NIC. For example, suppose that the virtual NIC 308 that is emulated by the NIC emulator 411 is a standard NIC that provides direct memory access (DMA) capabilities. Suppose further that an application 360 within the VM 300 generates a data packet for transmission to a destination on the network. The VM's guest network software 338 encapsulates the data packet into one or more Ethernet frames in a conventional manner and forwards the frames to the NIC driver 348. The NIC driver attempts to set up the virtual NIC 308 to perform a DMA transfer of the data frame. The NIC emulator 411 responds to the NIC driver 348 in the manner that the NIC driver 348 expects the virtual NIC 308 to respond. The NIC emulator 411 may copy the data frame to a new location, emulating the expected DMA transfer, or it may cause the physical NIC to perform the expected DMA transfer.
In any case, the data frame is conveyed from the NIC driver 348 to the physical NIC, which then transmits the data frame to the network. One method for conveying data frames between the NIC driver 348 and the physical NIC is described below in connection with a first embodiment of the invention. In any event, the NIC driver 348 thinks that it is interfacing with the virtual NIC 308 and that the virtual NIC 308 is providing a network interface, but the work is actually performed by the physical NIC, along with the NIC emulator 411 and possibly one or more other software units. Various techniques are known in the art for emulating a virtual NIC 308 in this manner to facilitate the transfer of data between the NIC driver 348 and a computer network, using the physical NIC.
In the bridged networking configuration of the Workstation product, each of the virtual NICs in the system is assigned a MAC (Media Access Control) address that is unique, at least within the virtual computer system. In particular, the MAC addresses of the virtual NICs are different from each other and from the MAC address of the physical NIC. The MAC addresses for the virtual NICs may be assigned manually by a user of the computer system, or they may be assigned automatically by the virtualization software. Each VM is generally also assigned a static or dynamic IP address, such as by using a DHCP (Dynamic Host Configuration Protocol) server. The IP address is preferably unique at least within the local network to which the virtual computer system is connected. Each of the VMs in the computer system may preferably use its respective MAC address and IP address in a conventional manner, just like a “real” computer system, to communicate with the host computer and other computers that are accessible through the network, along with other network devices and entities.
Any entity, either hardware or software, that may be accessed through an attached network, will generally be referred to as a “network entity.” Network entities may include, for example, a computer attached to the local network or to a remote network, a network printer or other network device, or a VM running in a remote computer. As described below, this invention may be implemented in a virtual computer system in which a virtual network is implemented within the host physical computer system, giving network access to other VMs running within the same physical computer system, as well as to software entities within the host world of the physical computer system. Accordingly, network entities may also include other VMs running on the same physical computer system, as well as software entities within the host world of the same physical computer system.
Suppose first that a wired Ethernet controller is used within the physical hardware 100. This wired Ethernet controller may be set up in a promiscuous mode, so that, as is well known, the controller passes all incoming data frames received from the network through to the networking software of the computer system, regardless of the MAC address contained in the destination field of the Ethernet headers. Also, wired Ethernet controllers generally pass all outgoing data frames from the networking software of the computer system onto the network, regardless of the MAC address that is contained in the source field of the Ethernet headers.
Using these characteristics of a wired NIC, the Workstation product enables data to be transferred between a VM within a virtual computer system and other network entities accessible through an attached network. Thus, for example, the VM 300 can send data, encapsulated into an IP data packet, containing the VM's IP address in the source address field of the IP header, to its virtual NIC 308, using its NIC driver 348. First, the guest network software 338 encapsulates the packet into one or more Ethernet frames, inserting the MAC address of the virtual NIC 308 into the source address field. The Ethernet frame is then forwarded to the NIC driver 348, which attempts to send it to the virtual NIC 308. The NIC emulator 411 causes the Ethernet frame to be conveyed to the physical, wired NIC, which then transmits the data frame onto the network, still containing the MAC address of the virtual NIC 308 in the source address field. The data frame is then routed to the appropriate network entity in a conventional manner.
The network entity may respond to the data frame, and send another data frame back to the virtual machine 300, using the IP address of the VM 300 and the MAC address of the virtual NIC 308 as the respective destination addresses for the data frame. The computer network(s) route the data frame from the network entity to the system 10, based on the IP address and the MAC address. The physical NIC retrieves the data frame from the network and, because the NIC is in promiscuous mode, passes it on to the networking software within the system 10, even though it does not contain the MAC address of the physical NIC. The data frame is conveyed from the physical NIC to the NIC driver 348, in a manner that makes it appear as if the frame were received from the network by the virtual NIC 308. Again, a method for conveying data frames between the physical NIC and the NIC driver 348 is described below in connection with a first embodiment of the invention. The NIC driver 348 passes the data frame on to the guest network software 338, which strips the Ethernet header and IP header from the data frame. The guest network software 338 then forwards the data to the appropriate application within the VM 300 in a conventional manner. The same technique can be used to enable other VMs in the system to access the computer network using the physical, wired NIC, but using a MAC address that is unique to the corresponding virtual NIC and an IP address that is unique to the VM.
Applications in the host world can also access the computer network, using the physical, wired NIC in a conventional manner. The host OS 220 includes a host network software package 222 that provides one or more network protocol stacks within the host OS, just like the guest network software 338 provides one or more network protocol stacks within the guest OS. The host OS 220 also includes a host NIC driver that is appropriate to the host OS and the physical NIC. The host network software 222 interfaces with the host NIC driver to use the physical NIC to communicate with other computers accessible through the network. These network communications in the host world use the MAC address of the physical NIC and the IP address of the host computer. The physical NIC transfers data frames between the network and the host NIC driver in a conventional manner. Of course, the physical NIC has no problem transferring data frames that contain its own MAC address in either the source field or the destination field. Thus, the multiple virtual computers and the host world are all able to share access to the computer network using the single physical NIC, but with each computer using its own MAC address and its own IP address.
This same approach does not work in all situations, however. For example, the approach generally does not work if the system hardware 100 has a wireless NIC 108, as illustrated in FIG. 1, instead of a wired NIC. The wireless NIC 108 typically interfaces with a wireless access point that implements the same wireless standard as the wireless NIC. For example, if the wireless NIC is the Linksys WUSB11 Wireless USB Adapter, as mentioned above, the NIC might interface with a Linksys WAP11 Wireless Network Access Point. With such wireless interfaces, standard Ethernet data frames are transmitted over a radio frequency (RF) communication link between the wireless NIC 108 and the wireless access point.
Applications in the host world can communicate with other network entities through the wireless access point using the MAC address of the wireless NIC 108. The host world can send various Ethernet data frames to remote network entities using the MAC address of the wireless NIC 108 in the source address field of the Ethernet data frames, and remote network entities can send various Ethernet data frames to the host world using the MAC address of the wireless NIC 108 in the destination address field of the Ethernet data frames. It is known, however, that such a communication link generally cannot be established using a MAC address that does not match the MAC address of the wireless NIC 108. Thus, the VM 300 cannot establish such a communication link through the wireless access point using the MAC address of the virtual NIC 308. Only the MAC address of the wireless NIC 108 may be used to establish such a connection.
What is needed, therefore, is a method for enabling multiple virtual computers, or a physical computer and one or more virtual computers, to share a physical network connection when there is a limitation on the use of network physical addresses, such as when the network connection consists of a typical wireless network interface.